This PR introduces a new naming convention to support multiple environment deployments:

• Environment Label (environment-label): The pre-defined deployment target you specify when triggering the workflow (dev, staging, prod-multitenant). This is what you select from the dropdown in GitHub Actions.
• Environment Name (env-name): The actual environment names defined in your environments.yaml file (dev.aws, dev.azure, staging, etc.). These are the specific deployment configurations that map to the environment label.

Why we need this distinction:

• One-to-Many Mapping: A single environment label can now map to multiple environment names (e.g., dev → dev.aws, dev.azure), enabling parallel deployments to different cloud providers
• Non-explicit Mapping: If an environment has an env-name that is the same as the deployment target (i.e. an env-name of dev and a deployment target dev) it will automatically deploy to that environment.

This supports the desired config change of having different environments that map to a single "environment":

schema_version: "v1" # This is used to validate the file structure and is not used by the agentex CLI
environments:
  dev-aws:
    environment: "dev"
    kubernetes:
      namespace: "sgp-000-hello-acp"
    auth:
      principal:
        user_id: ...
        account_id: ...
    helm_overrides:
      ...
  dev-azure:
    environment: "dev"
    kubernetes:
      namespace: "sgp-000-hello-acp"
    auth:
      principal:
        user_id: ...
        account_id: ...
    helm_overrides:
      ...

Backwards compatability:

• This introduces new helper methods that are used in the deployment pipelines and doesn't change any existing methods. This is purely an additive change so it will not break any older code, or anyone using these helper function sin older SDKs.

Tests against internal scale agents:

• New Process (NB. all agents that did not deploy was not because of this new code)
• Old Process - N.B. the deployment failed because the agent doesn't have the correct creds setup but the deployment to the cluster works correctly.

N.B. There was a large diff generated by linter for some reason